What
Support for an Interface Means
Besides the IUnknown
interface, an ActiveX Control or
COM Object for that matter expresses
whatever optional functionality it supports through additional interfaces. This
is to say that no other interfaces are required above IUnknown. To that
end, the following table lists the interfaces that an ActiveX Control might
support, and what it means to support that interface. Further details
about the methods of these interfaces are given in a later section.
Interface |
Comments/What
it Means to Support the Interface |
IOleObject |
If the
control requires communication with its client site for anything other than
events (see IConnectionPointContainer), then IOleObject is a
necessity. When implementing this interface, the control must also support
the semantics of the following methods: SetHostNames, Close, EnumVerbs,
Update, IsUpToDate, GetUserClassID, GetUserType, GetMiscStatus,
and the Advise, Unadvise, and EnumAdvise methods that
work in conjunction with a container s IAdviseSink implementation. A
control implementing IOleObject must be able to handle IAdviseSink
if the container provides one; a container may not, in which case a control
ensures, of course, that it does not attempt to call a non-existent sink. |
IOleInPlaceObject |
Expresses
the control s ability to be in-place activated and possibly UI activated. This
interface means that the control has a user interface of some kind that can
be activated, and IOleInPlaceActiveObject is supported as well.
Required methods are GetWindow, InPlaceActivate, UIDeactivate,
SetObjectRects, and ReactivateAndUndo. Support for this
interface requires support for IOleObject. |
IOleInPlaceActiveObject |
An in-place
capable object that supports IOleInPlaceObject must also provide this
interface as well, though the control itself doesn t necessarily implement
the interface directly. |
IOleControl |
Expresses
the control s ability and desire to deal with (a) mnemonics (GetControlInfo,
OnMnemonic methods), (b)
ambient properties (OnAmbientPropertyChange), and/or (c) events
that the control requires the container to handle (FreezeEvents). Note
that mnemonics are different than accelerators that are handled through IOleInPlaceActiveObject: mnemonics have associated UI and are active
even when the control is not UI active. A control s support for mnemonics
means that the control also knows how to use the container s IOleControlSite::OnControlInfoChanged
method. Because this requires the control to know the container s site, support
for mnemonics also means support for IOleObject. In addition,
knowledge of mnemonics requires in-place support and thus IOleInPlaceObject. If a
control uses any container-ambient properties, then it must also implement
this interface to receive change notifications, as following the semantics of
changes is required. Because ambient properties are only available through
the container site s IDispatch, ambient property support means that
the control supports IOleObject (to get the site) as well as being able
to generate IDispatch::Invoke calls. The FreezeEvents
method is necessary for controls that must know when a container is not going
to handle an event this is
the only way for control to know this condition. If FreezeEvents is
only necessary in isolation, such that other IOleControl methods are
not implemented, then IOleControl can stand alone without IOleObject
or IOleInPlaceObject. |
IDataObject |
Indicates
that the control can supply at least (a) graphical renderings of the control
(CF_METAFILEPICT is the minimum if the control has any visuals at all) and/or
(b) property sets, if the control has any properties to provide. The methods GetData,
QueryGetData, EnumFormatEtc, DAdvise, DUnadvise,
and EnumDAdvise are required. Support for graphical formats other than
CF_METAFILEPICT is optional. |
IViewObject2 |
Indicates
that the control has some interesting visuals when it is not in-place active.
If implemented, a control must support the methods Draw, GetAdvise,
SetAdvise, and GetExtent. |
IDispatch |
Indicates
that the control has either (a) custom methods, or (b) custom properties that
are both available via late-binding through IDispatch::Invoke. This
also requires that the control provides type information through other IDispatch
methods. A control may support multiple IDispatch implementations
where only one is associated with IID_IDispatch the others must have their own unique dispinterface
identifiers. A control
is encouraged to supply dual interfaces for custom method and property
access, but this is optional if methods and properties exist. |
IConnectionPointContainer |
Indicates
that a control supports at least one outgoing interface, such as events or
property change notifications. All methods of this interface must be
implemented if this interface is available at all, including EnumConnectionPoints
which requires a separate object with IEnumConnectionPoints. Support for
IConnectionPointContainer means that the object also supports one or
more related objects with IConnectionPoint that are available through IConnectionPointContainer
methods. Each connection point object itself must implement the full IConnectionPoint
interface, including EnumConnections, which requires another
enumerator object with the IEnumConnections interface. |
IProvideClassInfo[2] |
Indicates
that the object can provide its own coclass type information directly through
IProvideClassInfo::GetClassInfo. If the control supports the later
variation IProvideClassInfo2, then it also indicates its ability to
provide its primary source IID through IProvideClassInfo2::GetGUID.
All methods of this interface must be implemented. |
ISpecifyPropertyPages |
Indicates
that the control has property pages that it can display such that a container
can coordinate this control s property pages with other control s pages when
property pages are to be shown for a multi-control selection. All methods of
this interface must be implemented when support exists. |
IPerPropertyBrowsing |
Indicates
the control s ability to (a) provide a display string for a property, (b)
provide pre-defined strings and values for its properties and/or (c) map a
property dispID to a specific property page. Support for this interface means
that support for properties through IDispatch as above is provided. If (c) is
supported, then it also means that the object s property pages mapped through
IPerPropertyBrowsing::MapPropertyToPage themselves implement IPropertyPage2
as opposed to the basic IPropertyPage interface. |
IPersistStream |
See Persistence
Interfaces |
IPersistStreamInit |
See Persistence
Interfaces section. |
IPersistMemory |
See
Persistence Interfaces section. |
IPersistStorage |
See
Persistence Interfaces section. |
IPersistMoniker |
See
Persistence Interfaces section. |
IPersistPropertyBag |
See
Persistence Interfaces section. |
IOleCache[2] |
Indicates
support for container caching of control visuals. A control generally obtains
caching support itself through the OLE function CreateDataCache. Only
controls with meaningful static content should choose to do this (although it
is not required). If a control supports caching at all, it should simply
aggregate the data cache and expose both IOleCache and IOleCache2
interfaces from the data cache. A control implementing IOleObject must
be able to handle IAdviseSink if the container provides one; a container
may not, in which case a control ensures, of course, that it does not attempt
to call a non-existent sink. |
IExternalConnection |
Indicates
that the control supports external links to itself; that is, the control is
not marked with OLEMISC_CANTLINKINSIDE and supports IOleObject::SetMoniker
and IOleObject::GetMoniker. A container will never query for this
interface itself nor call it directly as calls are generated from inside
OLE s remoting layer. |
IRunnableObject |
Indicates
that the control differentiates being loaded from being running, as some
in-process objects do. |